% ----------------------------------------------------------------------- %
% Arquivo: cap2.tex
% ----------------------------------------------------------------------- %

\chapter{Qualidade de Serviço em redes IP}
\label{c_cap2}

As redes \ac{IP}, originalmente baseadas em serviço de melhor
esforço\footnote{Melhor esforço é uma classe de tráfego utilizada em redes que envia
fluxos de dados, ao mesmo tempos com largura de banda compartilhada com demais
fluxos de dados enviados, tornando-os concorrentes entre si. Em caso de
congestionamento de dados, os pacotes são descartados sem qualquer critério nem
distinção, mas se propondo a fazer o melhor possível para a entrega de cada
pacote.}, vêm evoluindo
para redes de comunicação capazes de suportar fluxos de pacotes com diferentes
requisitos, em particular o tráfego multimídia. Surge então a necessidade de
garantir níveis apropriados de Qualidade de Serviço nestas redes.

Neste capítulo o termo \ac{QoS} é conceituado e faz-se uma rápida abordagem dos
modelos clássicos de \ac{QoS} para redes \ac{IP}: o \textit{\ac{DiffServ}} e o
\textit{\ac{IntServ}}. Ao final, os
protocolos de sinalização são caracterizados como elementos de apoio a
construção destes modelos e como ferramenta de interconexão entre os mesmos.

\section{Histórico de QoS em Redes}

Nos primórdios das telecomunicações a comunicação era feita dedicando circuitos
para a transmissão de uma determinada mídia. Esta abordagem é a base das redes
com comutação de circuitos, cujo principal exemplo são as redes de telefonia. Com a evolução
dos computadores surgiram as redes de comutação de pacotes, dominadas na atualidade pela tecnologia de redes \ac{IP}. No início, era possível determinar exatamente a
aplicabilidade destas redes: as redes com comutação de circuitos basicamente
para o transporte de voz e com comutação de pacotes para o transporte de dados.
A figura \ref{fig_cap2_fig1} representa esta classificação.


\begin{figure}[!htpb]
	\centering
	\mbox{
		\subfigure[Antigo Modelo de rede]{
		\label{fig_cap2_fig1}
		\includegraphics[scale=.4]{figs/cap2_1}}
		\qquad
		\subfigure[Atual Modelo de rede]{
		\label{fig_cap2_fig2}
		\includegraphics[scale=.4]{figs/cap2_2}}
	}
	\caption{Modelos de redes}
	\label{fig_cap2}
\end{figure}

As redes com circuitos dedicados garantem quase que completamente a integridade
dos fluxos transportados, dado que existem recursos especificamente dedicados
para eles. Já as redes por pacotes se utilizam de uma forma de multiplexação que
pode eventualmente comprometer a cadência e gerar tempo de atraso de pacotes de
um fluxo e perda de pacotes.

A busca por qualidade de serviço remonta aos tempos dos
sistemas telefônicos clássicos. Park \cite{PARK} aponta que no início da rede de
telefonia, haviam duas medidas chave de qualidade de serviço, probabilidade de
bloqueio e a capacidade de percepção de usuários. A probabilidade de bloqueio,
é a probabilidade de não conseguir fazer a chamada por conta da
indisponibilidade de um tronco do circuito. A outra medida de qualidade foi a da
percepção de voz, que dependia da qualidade de transmissão ponto a ponto durante
uma chamada.

Com a evolução das tecnologias, a convergência digital passou a ser uma
realidade. As redes para o transporte de dados e de voz e imagem tendem a ser
integradas: são as redes redes convergentes, conforme mostrado na figura
\ref{fig_cap2_fig2}.

As redes convergentes, com interfaces abertas e com capacidade de transmitir
dados multimídias, como a voz, exploram plenamente as tecnologias de ponta para
oferecer serviços sofisticados. Em particular, as redes IPs surgem como uma
solução madura e barata para esta finalidade. Entretanto, visto que o protocolo
IP não foi originalmente concebido para suportar este tráfego multifacetado, é
que surge a necessidade de incorporar soluções que forneçam alguma qualidade de
serviço a estes fluxos. Dentro deste contexto a \ac{IETF} propõe alguns modelos
para
o provimento de \ac{QoS}. Nas seções subsequentes são apresentados os modelos
\textit{IntServ}
e \textit{DiffServ} e, uma breve discussão sobre o uso de protocolos de
sinalização para a viabilização dos mesmos.

\section{O Conceito e Parâmetros de QoS}
\label{c_cap_conceito_qos}

Park \cite{PARK} define \ac{QoS} a partir de dois pontos de vista: a QoS
experimentado
pelo usuário e a \ac{QoS} do ponto de vista da rede. Da perspectiva do usuário
ou de
uma aplicação, a \ac{QoS} é a percepção da qualidade que ele recebe da rede para
um
serviço específico que envolva  a transmissão da voz, vídeo e dados. Na
perspectiva da rede, a \ac{QoS} refere-se a capacidade desta, de fornecer a
\ac{QoS}
percebida pelo usuário.

Park \cite{PARK} cita ainda que a \ac{ISO}, órgão que organiza padrões
internacionais
com sede na Suíça, define qualidade como ``a soma das características de uma
entidade como a capacidade de suportar e satisfazer necessidades implícitas dado por um conjunto de características intrínsecas''. A \ac{ITU-T}
(Recomendação E.800 \cite{ITUTE800}) define basicamente Qualidade de Serviço
como "o efeito coletivo do desempenho de um serviço que irá determinar o
grau de satisfação de um usuário deste serviço".

A \ac{IETF} considera \ac{QoS} \cite{MARCHESE} como a capacidade de segmentar
o tráfego
ou diferenciar os tipos de tráfego para a rede, a fim de tratar determinados
fluxos de tráfego de maneira diferente dos outros. \ac{QoS} engloba tanto o
serviço
de
categorização como também o desempenho global da rede para cada categoria.
De forma similar, a \ac{ITU-T} na resolução E-800 \cite{ITUTE800}, destaca a
necessidade da rede oferecer requisitos de performance e operabilidade para o
provimento de \ac{QoS}.

Para este trabalho será assumido que \ac{QoS} será a garantia oferecida pela
rede de
que certos parâmetros serão mantidos entre níveis pré-acordados. Neste sentido,
os principais parâmetros considerados serão a largura de banda, o retardo
fim-a-fim, a variação do atraso entre pacotes (\textit{jitter}) e as perdas de pacotes.

A largura de banda mede o número de \textit{bits} por segundo em média que
passam pela
rede. O atraso fim-a-fim refere-se ao atraso médio dos pacotes de um fluxo desde
a fonte até o destino. O \textit{jitter} é a variação do atraso entre pacotes
para um
mesmo fluxo. Em geral, pacotes sofrem atraso diferenciado na rede, o que faz com que fluxos com cadência fixa, por exemplo originados pela digitalização da
voz, sofrerem um total descompasso entre pacotes.

É interessante ainda observar que os parâmetros de \ac{QoS}
definidos pela \ac{ITU} \cite{MARCHESE}  são colocados de uma forma um pouco
diferenciada, ou melhor, na forma de
indicadores de desempenho conforme colocado abaixo:

\begin{itemize}
 \item IPLR – IP \textit{Packet Loss Ratio} (Taxa de perdas)
 \item IPTD – IP \textit{Packet Transfer Delay} (Atraso)
 \item IPDV – IP \textit{Packet Delay Variation} (Conhecido como Jitter)
 \item IPER – IP \textit{Packet Error Ratio}. (Taxa de erro)
\end{itemize}

Os indicadores acima podem ser entendidos como métricas que classificam classes
de \ac{QoS} conforme as mensurações de \ac{QoS} (atraso, variação do atraso,
perda) e os
requerimentos para minimizar a percepção de problemas.

Os mecanismos de \ac{QoS} são aplicados, em geral, a saída de um nó da rede,
onde a perda de pacotes é ocasionada, na maioria das vezes, por estouro de
\textit{buffers} associados as interfaces de roteadores. Os mecanismos
envolvidos
neste controle, a interação entre os mesmos, bem como as políticas e formas de
gerenciamento neste processo constituem um modelo de QoS.

\section{Modelo IntServ}

Em redes de computadores, \textit{IntServ}, ou serviços integrados, é uma
arquitetura que
especifica os elementos para garantir a qualidade de serviço em
redes com requisitos estritos por fluxo. A idéia do \textit{IntServ} é que cada
roteador
que o implementa, e todas as aplicações que requerem algum tipo de
garantia, tem de fazer uma reserva individual por fluxo.

O \textit{IntServ} provê, portanto, a garantia de qualidade de serviço para
fluxos
individuais, mantendo estados (incluindo reserva de estados) associados ao fluxo
fim a fim, em todos os roteadores por onde este irá passar. Esta arquitetura
foi projetada para a internet, porém o processo de alocação de recursos do
\textit{IntServ} tem um custo alto para os roteadores, pois cada roteador terá
de manter as informações do fluxo \cite{KUROSE}.

Para manter os estados da rede com fins de fornecer QoS para fluxos individuais,
o \textit{IntServ} se utiliza de uma entidade de sinalização, o \ac{RSVP}
(\textit{Resource ReSerVation Protocol}). Este protocolo é capaz de iniciar e 
manter o estado da reserva do \textit{IntServ} por fluxo, além de armazenar
apontadores por fluxo, que permitem sinalizar na direção e contra o fluxo. O
estado dos diferentes fluxos recebidos deve ser mantido e monitorado nos
roteadores. Esta abordagem difere acentuadamente do serviço de melhor esforço
fornecidos pela internet, pois o fluxo recebe uma garantia de banda dentro da
rede.

O \textit{IntServ} \cite{RFC1633} pode fornecer dois tipos de serviços: o
serviço de
carga controlada e os serviços garantidos. O serviço de carga controlada fornece
a um fluxo uma aproximação de QoS que o mesmo fluxo receberia se a rede
estivesse livre. Clientes que requisitam este serviço \cite{RFC2211}, fornecem
aos componentes intermediários da rede a especificação de tráfego (\ac{TSPEC}): uma estimativa do tráfico que
irão gerar. Os elementos da rede alocam recursos necessárias a manutenção deste
tráfego. Um controle de admissão deve ser aplicado na requisição do serviço.
Este controle pode envolver a verificação de recursos de banda no enlace,
espaço em \textit{buffers} internos, e até mesmo capacidade de processamento
para o encaminhamento de pacotes.

O serviço garantido do \textit{IntServ} \cite{RFC2211} faz com que seja possível
fornecer um serviço que garanta tanto o limite de atraso como a largura de banda
para um fluxo singular. Este serviço objetiva atingir aplicações que necessitam
garantir rigidamente que os pacotes de um fluxo não serão atrasados por um
limite superior de tempo, após terem sidos transmitidos pela fonte. A invocação
deste serviço deve ser acompanhada da especificação do fluxo, \ac{TSPEC}, e dos
requisitos de QoS do mesmo, \ac{RSPEC}. 

Como mencionado anteriormente, \textit{IntServ} depende do início e da
manutenção da
reserva de fluxo por estados, o que, obviamente, limita a sua escalabilidade e
sua implantação no núcleo da Internet. Redes do núcleo da estrutura, que têm de
lidar com milhões de fluxos simultaneamente, não podem tolerar as limitações de
escalabilidade \textit{IntServ}. Entretanto, o modelo \textit{IntServ} puro pode
ser aplicado em
domínios \textit{stub}\footnote{Uma rede stub é um segmento de rede com uma faixa de endereço, que é um subconjunto da faixa de endereço de outro segmento (a rede pai)}, nas pontas da internet, ou mesmo, em redes IP dedicadas.

%\footnote[\textit{stub}]{Uma rede stub é um segmento de rede com uma faixa de endereço, que é um subconjunto da faixa de endereço de outro segmento (a rede pai)}

\section{Modelo DiffServ}
	
O \textit{DiffServ} (\textit{Differentiated Services}) \cite{RFC2475}, ou serviços
diferenciados,
é uma proposta da IETF para lidar com o problema da escalabilidade apresentado
pelo \textit{IntServ}. O \textit{DiffServ} controla a agregação de tráfego através do
campo DS (\ac{DSCP}) do cabeçalho \ac{IP}, sem a necessidade
de manter o estado e a sinalização do fluxo em todo roteador.

O \textit{DiffServ} foi projetado com o intuito de agregar fluxos individuais em
classes. Na borda de um domínio \textit{DiffServ}, o roteador irá receber fluxos
marcados com sinalização de \ac{QoS}, classificá-lo e condicioná-lo em classes para
encaminhar ao
destino, passando por dentro deste domínio. No núcleo do Domínio, os roteadores
adaptados a trabalharem com o \textit{DiffServ}, encaminham o fluxo conforme
tratamento, prioridade e roteamento.

Os roteadores com entidades \textit{DiffServ} fazem o tratamento do fluxo
através do \ac{PHB}, que processam as classes
\textit{DiffServ} conforme o comportamento pré-configurado. Os Fluxos dentro do
domínio \textit{DiffServ} são definidos em 3 classes básicas: melhor esforço
(\textit{Best Effort}), encaminhamento acelerado (\ac{EF}) e encaminhamento assegurado (\ac{AF}).

A diferenciação e marcação das classes é marcada no campo \ac{DSCP} do cabeçalho \ac{IP}, conforme a figura \ref{fig:cap2_dscp}.

\begin{figure}
\centering
\begin{verbatim}
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |         DSCP          |  CU   |
      +---+---+---+---+---+---+---+---+

        DSCP: differentiated services codepoint
        CU:   Atualmente não utilizado

\end{verbatim} 
\caption{Campo \textit{DiffServ Code Point}}
\label{fig:cap2_dscp}
\end{figure}

O \textit{DiffServ} aceita uma combinação de 64 (0 a 63) classes de serviço
\cite{IANADSCP}, sendo uma faixa com 32 valores de classe de \ac{DSCP} citado pela
RFC2434 \cite{RFC2434} e demais ítens para teste e implantação futura. O modelo
\textit{DiffServ}
fornece maior escalabilidade devido a menor quantidade na alocação de recursos.
No modelo \textit{DiffServ} não é necessário efetuar uma reserva específica para
cada
fluxo. Os fluxos são agregados em classes de serviços  de modo que não há
controle de estado individual.

Diferente do \textit{IntServ}, o \textit{DiffServ} não tem um protocolo de
sinalização específico
e que comporte a arquitetura em classes. Contudo, neste trabalho será mostrado
que o protocolo de sinalização NSIS pode se apresentar como uma alternativa para
sinalização que pode ser utilizada em domínio \textit{DiffServ}, permitindo um
melhor aproveitamento de recursos nos roteadores.

\section{Os protocolos de Sinalização e os Modelos de QoS}
\label{c_cap_signaling}

Um dos principais componentes das infra-estruturas em todas as redes de
telecomunicações, desde a rede telefônica, redes de computadores, ou a internet
e suas aplicações, é o seu sistema de sinalização. Basicamente um protocolo de
sinalização permite identificar uma requisição específica entre entidades,
sincronizar a troca de informações entre pontos distintos além de outras
aplicações.

Em redes de telefonia, a sinalização é feita para identificar troncos,
armazenar estado no caminho da chamada e carregar informações referente ao
chamador, originador de uma requisição. Em redes de computadores, o protocolo de
sinalização pode ter funcionalidades similares de reserva de recursos, enviando
os dados do requisitante até o destino para um devido encaminhamento de um
fluxo.

O protocolo de sinalização define as opções de serviço como a solicitação do início da comunicação, a confirmação do pedido, a configuração da transmissão de dados, a resposta ao envio de informações e a desconexão definindo também subprotocolos responsáveis por controles específicos. Um protocolo de sinalização para especificação de fluxo e provimento de QoS pode especificar entre outros parâmetros a codificação de um tráfego, a configuração de rota, o transporte de dados, segurança, cabeçalho, endereçamento.

O protocolo de sinalização pode ser implementado em modelos fim-a-fim, de um
ponto de uma rede a outro, não levando em conta os componentes intermediários
da rota, ou ainda, o modelo \textit{hop-by-hop}, ou seja, os pacotes são
enviados de roteador a roteador, até ao destino final mantendo o estado nos hosts no meio do caminho.

Um protocolo de sinalização gerencia os estados de fluxo. Estes estados são armazenados em roteadores. Para isto, utiliza-se de mensagens de sinalização para reserva de estado, desconexão de estado e mensagens de alerta, como erro. Um estado é o conhecimento do roteador de determinado fluxo para tal protocolo. Um roteador somente armazena o estado de protocolos por ele conhecido, atráves das mensagens de sinalização deste.

Duas grandes abordagens para a sinalização podem ser identificadas:
\textit{hard-state}
e \textit{soft-state}. O termo \textit{soft-state} foi cunhado por Clark
\cite{CLARK}, que
descreveu o conceito de atualização periódica de estados definidos inicialmente
por uma requisição. Este procedimento de \textit{refresh} (atualização)
é transparente para o sistema final e garante, por exemplo, que no caso de um
dos pontos finais seja removido, os estados mantidos pelas entidades envolvidas
ao longo de uma rota sejam automaticamente removidos.

No caso de \textit{hard-state} o estado da sinalização é mantido nos nós. Desde
que o
estado é instalado, a menos que explicitamente removido, pode manter-se durante
um tempo previamente definido. Um protocolo \textit{hard-state} requer um
mecanismo
para a remoção de estados já sem comunicação. Neste caso, um mecanismo a ser
utilizado é ter um mecanismo de tempo de vida (\textit{timeout}) e/ou uma
mensagem
explícita solicitando a remoção do estado (\textit{teardown}).

\subsection{O Protocolo de Sinalização como Elemento de Interligação de Modelos
de QoS}

A sinalização de QoS surgiu inicialmente como um componente do modelo
\textit{IntServ}. Entretanto, a sua aplicação na interconexão de domínios com
diferentes modelos de QoS vem se tornando uma realidade,
por exemplo, no projeto europeu \ac{EuQoS}\cite{masipbruin2007}. Na
própria \ac{IETF} \cite{RFC2998} é discutido o uso do protocolo \ac{RSVP} na
interconexão de domínios com diferentes modelos de QoS e, como será visto
adiante, o protocolo \ac{NSIS}, apresenta mecanismos interessantes para este fim. 

No sistema \ac{EuQoS}, por exemplo, a sinalização fim-a-fim é desviada na entrada de
roteadores de ingresso dos domínios atravessados, de forma a visitar as
entidades de gerenciamento de recursos dos domínios (GR). O GR realiza tarefas
de controle de admissão e de sinalização adicional dentro do domínio e, então,
encaminha a sinalização para o roteador de egresso do domínio. As mensagens de
sinalização são, por sua vez, encaminhadas para o roteador de ingresso do próximo
domínio, onde o processo se repete até atingir o ponto final da comunicação.

Em adição, os modelos \textit{DiffServ} podem se beneficiar da sinalização para
obter um
melhor aproveitamento de recursos. No capítulo que se segue, o protocolo NSIS,
tido como sucessor do RSVP, será apresentado com maiores detalhes, sendo
mostrado os mecanismos que o tornam interessante para as tarefas acima, além do
comportamento mas comumente conhecido que é a reserva por fluxo.